fix(runtime): honor isRetryable flag in provider retry classifier - #3812

The red test check points at something worth knowing before you rework this: the top-level case is already handled on main.

isTransportFailure (provider-error-classification.ts:161-167) already matches an AI_APICallError with isRetryable === true and sets transportFailure, which classifyProviderFacts:746 turns into 'Network', which providerRetryMetadata:244 treats as retryable. So your TLS example already retries today.

That is exactly why the assertion fails. assert.equal(classifyError(tlsFailure), 'AI_APICallError') gets 'Network' — and 'Network' is the success signal. 'AI_APICallError' is the fallback classificationTarget.name returned when no evidence matched at all, so receiving it would mean the flag was not recognised. That first test can go.

Your second test is a real gap. In honors isRetryable on a cause error..., the flag sits on the cause and not on the top level. isTransportFailure's cause walk only inspects code (TRANSPORT_FAILURE_CODES, ERR_SSL_*, ERR_TLS_*, UND_ERR_*) and never looks at isRetryable, so that error falls through to non-retryable. Worth fixing.

But the fix belongs in isTransportFailure, not in providerRetryMetadata. isTransportFailure is the single authority for "was this a transport failure", and isRetryableInChain adds a second one beside it. The two disagree by construction: the new branches only affect retryable, never classifyError, so a cause-flagged error becomes retryable while still classifying as Other. Retry and diagnostics would then tell different stories about the same failure, and errorPresentationFromClass would show no network reason for something being retried as one.

Teaching the existing cause walk to accept isRetryable === true alongside the code checks is roughly one condition, keeps classification and retry deciding from the same fact, and preserves the 'Network' semantics.

AI-assisted review: I traced isTransportFailure, classifyProviderFacts, and providerRetryMetadata on main and ran the failing assertion's path myself. No tests run. AI review is not independent human review.